In a service scenario of a conventional database application, frequent data updates are processed by means of online transaction processing (On-Line Transaction Processing, OLTP for short), data is imported into a data warehouse by means of an extraction-transformation-loading (Extraction-Transformation-Loading, ELT for short) operation, and on-line analytical processing (On-Line Analytical Processing, OLAP for short) is implemented in the data warehouse to support a complicated structured query language (Structured Query Language, SQL for short) query to generate a report. Because a read/write concurrent operation at the bottom layer of a database needs to be protected by using a complicated lock mechanism, frequent data updates may cause an interruption of an OLAP query and lower query efficiency. In order to improve the query efficiency, an OLTP service and an OLAP service are always not allowed to run in a same database management system; however, a direct problem brought by such a limitation is that data timeliness is poor and the report cannot reflect the latest service situation. Moreover, the design and the implementation of the database system also have to face various complicated problems brought by concurrency, for example, deadlock and priority inversion.
In order to implement read/write concurrency of OLAP and OLTP in a mixed scenario in a database application while improving the query efficiency, a solution in the prior art is: isolating an OLTP service from an OLAP service by using a data snapshot. A data snapshot is a subprocess created by using a fork( ) algorithm, where the subprocess and a main process share same data, and the OLTP service runs in the main process, and the OLAP service runs in the subprocess. Data reading/writing of the subprocess does not affect memory data. When the main process executes a data update, after an original data page is copied, a write operation is performed on a new page; therefore, data that is being accessed in the subprocess is not affected. However, in the solution in the prior art, data synchronization between the main process and the subprocess needs to depend on creation of the subprocess, which brings about unnecessary initialization overheads. In addition, when an update operation is performed in the main process, a page needs to be copied, which greatly affects performance. Large updated data occupies excessive memory.